The Simple Network Management Protocol (SNMP) is an application-layer protocol designed to facilitate the exchange of management information between network devices. By using the SNMP-transported data (such as packets per second and network error rates), the network administrators can more easily manage the network performance, find and solve network problems, and plan network expansion.
Like the Transmission Control Protocol (TCP), the Simple Network Management Protocol (SNMP) is an Internet protocol.
Today, the SNMP is the most popular protocol for managing different commercial inter-networks as well as those used in Universities and Research Organizations.
The SNMP protocol is part of the Internet network management architecture. This architecture is based on the interaction of entities, as described in the following.
As specified in the Internet Request For Comments (RFCs), a network management system comprises:
Network Elements: sometimes called Managed Devices, which are hardware devices such as computers, routers and access servers, terminal servers, switches and bridges, hubs, computer hosts, or printers, connected to managed networks. The Network Elements collect and store management information and make this information available to the Network Management Station (NMSs) using the SNMP protocol;
Agents: the Agents are network-management software modules that reside in the Network Elements. The Agents collect and store management information such as the number of error packets received by a network element. An Agent has local knowledge of management information and is configured to translate that management information into a form that is compatible with the SNMP protocol;
Managed Object: a Managed Object is a characteristic of something that can be managed. For example, a list of currently active Transmission Control Protocol (TCP) circuits in a particular host computer is a Managed Object. The Managed Objects differ from variables, which are particular object instances; for example, an object instance is a single active TCP circuit in a particular host computer;
Management Information Base (MIB): a MIB is a collection of hierarchically organized information. A MIB is a collection of Managed Objects residing in a virtual information store; the collections of related Managed Objects are defined in specific MIB modules. The Management Information Bases are accessed by using a network management protocol, such as e.g. the SNMP protocol;
Network Management Station (NMSs): sometimes called consoles, these devices execute management applications that monitor and control Network Elements. At least one NMS must be present in each managed environment. The network management station can be a workstation or a personal computer; and
Management Protocol: a Management Protocol is used to convey management information between Agents and Network Management stations.
An Object Identifier (or object ID) uniquely identifies a Managed Object in the Management Information Base hierarchy. The MIB hierarchy can be depicted as a tree with a nameless root, the leaves of which are assigned by different organizations.
The top-level MIB object Identifiers belong to different standards organizations, while the lower-level object Identifiers are allocated by associated organizations.
The Network Management station manages the devices and provides a summary of the information learned, or reports locally stored management information.
In recent years, most network elements have been using a network management protocol based, e.g., on a Simple Network Management Protocol (SNMP), to manage network and monitor operations of respective network devices. The SNMP protocol is the most typical network management protocol, through which an SNMP manager and an SNMP agent can exchange data.
With reference to FIG. 1, a Network Management station 100 comprises a User Interface 102 and a Network Management Application 104. The Network Management station 100 manages three network elements 110, each of which comprises an Agent module 112 and a Managed Information Base (MIB) 114. The Network Management station 100 and the Agent modules 112 are able to exchange data message.
In particular, the standard error management of the SNMP protocol, version v1/v2/v3, is not enough powerful for most cases. In fact, the SNMP standard errors are related to the SNMP management only (see Table 1), and no mention is done to the device causes of the error. Table 1 refers to some standard SNMP Error Status Codes known in the art.
All constraints remarked in the MIB descriptions cannot be mapped or referred to in the error status.
However, the Network Management (TMN) applications must help the user for managing the errors and guiding the user through the troubles. Additional benefits are to reduce the Operating Expenditure (OPEX) and to support powerful tools for managing errors.
TABLE 1Error statusCodeNo_Error0Too_Big1No_Such_Name2Bad_Value3Read_Only4Gen_Err5No_Access6Wrong_Type7Wrong_Length8Wrong_Encoding9Wrong_Value10No_Creation11Inconsistent_Value12Resource_Unvailable13Commit_Failed14Undo_Failed15Authorization_Error16Not_Writable17Inconsistent_Name18
To solve this problem, the SNMP error management can be improved by including the error cause into the SNMP response message.
Some of the SNMP error codes cannot happen in a system where manager and agent are built based on the same model, e.g., the “Bad Type” error.
Usually, both manager and agent should know that an attribute “A” is of type “T”. The fact that the manager sends a wrong type is not a transient run-time condition, but it is an indication of incompatibility, e.g., a wrong version was installed. These error codes are useful to detect an installation/version selection problem, but after the problem is fixed, they will not happen any more. Another example is the “Wrong Length” error related to the length of octet strings.
Standard SNMP error codes are generic, protocol-oriented error codes. They mean things like “line already exists”, “read only”, “generic error”, “bad value”. It is difficult to say much more precise about the error happened. Sometimes errors are generated by the agent framework, based on some preliminary checks (maybe read-only permission and similar ones), possibly even without involving application code.
Besides the standard error codes (from 1 to 18—see Table 1), the SNMP protocol supports user-defined error codes. Theoretically a proprietary value is sent in the error field, but look out that doing so might compromise the interoperability with generic SNMP browsers, which do not expect proprietary values (unless properly configured to handle & recognize them), and this might not be acceptable for certain Network Elements/customers.
What the Manager can do is to isolate the context of the provisioning, and mapping the specific error-cause into “generic” error-code. The Manager uses this mapping (context specific) to display the associated probable cause description.
The “generic” error-codes that the Manager/Agent can reuse in different context are only three: “genErr”, “badValue”, “InconsistentValue”, but they are not sufficient to isolate each error causes we need to refer to.